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(57) ABSTRACT 

Two stages of PPP negotiations are adopted for users to 
access a virtual private network (VPN). The access concen- 
trator for providing PPP connections is designed to provide 
the two-stage connection. In the first stage, a user is verified 
as an authenticated VPN user, and a first network address is 
assigned. In the second stage, a service requested by the 
authenticated user is decoded for determining either the 
service being a VPN service or a non-VPN service. If the 
service is a non-VPN service, the request is processed by 
reference to the network address. Otherwise, a second PPP 
negotiation is executed between the access concentrator and 
a server in a VPN, and then the server of the VPN assigns 
the user a VPN address for providing VPN service. 

9 Claims, 3 Drawing Sheets 
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SYSTEM AND METHOD FOR ON-DEMAND authentication, RFC 2284) in addition to the modification on 

ACCESS CONCENTRATOR FOR VIRTUAL the authentication architecUire of RADIUS. That would 

PRIVATE NETWORKS require additional costs in implementation and program- 
ming. 

5 

BACKGROUND OF THE INVENTION SUMMARY OF THE INVENTION 

A. Field of the Invention Accordingly, it is an object of the present invention to 
™ , . 11 1 . * provide a system and method for an Access Concentrator to 
The present mvention generally relates to an access . j il . x/nxr _ 

^ ^ J, . 1 • * * 1 provide on-demand functions, so that a VPN user may 

concentrator for commumcating virtual private networks, lo * ^mxT - . *u a ♦ ♦ 

, *• I 1 ♦ J ^ request a non-VPN service to the Access Concentrator 

and more particularly to an on-demand access concentrator -Ju * u • . *u c.u 

/ ... r 1 • ♦ * 1 wi, without havmg to access the server of the VPN. 

capable of providmg users of virtual pnvate networks with " 

various choices of services before connecting to a server of ^ another object of the present invention to provide a 

the user's company. system and method for an Access Concentrator to provide 

n • c.u n • A * ,^ on-demand functions, which is easy to implement and 

B. DescnpUon of the Prior Art 15 • ".u i. f j .u 

^ requires very httle program revision, thereby to reduce the 

A virtual private network (VPN) 19 is a private data implementation costs and lime, 

network that makes use of the public telecommunication . , .i. • . j j r 

.J, , 11 . . J • T-i/^ 1 A In accordance with the invention, a system and method tor 

infrastructure as illustrated m FIG. 1. A company or corpo- , „ ^ - -jjr ^r-* i 

. .J * 1 1* • 1 1 on-demand Access Concentrator is provided for Virtual 

rationl4 can use a wide-area network 15 as a single large n-^xr*. ir™.. i - ^ 

, , , , . . . J - . * • J -7/1 Pnvate Networks. The invention mvolves m performing two 

local area network via a contracted internet service provider ^ - ^^^^ . . a j u r *i. j nnn 

/ic-mii A ^mxT n »i. xmxTin • *u steps of PPP negotiations. And before the second PPP 

(ISP) 13. A VPN user 11 may connect to the VPN 19 via the ^ . . . r , . ^ • • -a a 

Tor> ^-1 • r> • * * r» • * i- * i ArnvrT»\ negotiation IS performed, an on-dcmand scrvice IS providcQ 

ISP 13 using Point -to-Point Tunnehng Protocol (PPTP). r .u i . i -n. ^ . r»nn f* 

nivm • * f 4U T * 4> * 1 *i. * 11 for the dial-up user to choose. The first PPP negotiation is 

PPTP is an extension of the Internet's protocol that allows - ..J, r^-i j„« 

^. , , J 5. ■ . performed between a host machme of a dial-up user and an 

companies or corporations to extend their own corporate \ „ * * i *u c . nnn .* *u 

* 1 *u u • * 1 ii: *u ui- I ♦ ♦ Access Concentrator. In the first PPP negotiation, the 

network through pnvate ninnels 16 over the pubhc Internet ^5 ^. r *i. j- i n u u i j if *i, 

15. With PFtT user of a PC with PPP cUent support is ^"'hentiaty of the dial-up user wUl be checked. If the 

able to dial-up PSTNs 12 to connect to an ISP 13 and then «^'^'-"P '^^^^^"'l "f", ^ "^'S"!^ 

connect securely to a server 14 elsewhere in the user's VPN • 'f'"' " lewnetwork address. Tten the d.al-up user is freeto 

- n ^ \ , J * t *♦ choose a VPN service or a non- VPN service, such as FTP, 

19. Consequently, a company no longer needs to lease its ™, xxnxnxj nno ir *i- j- i . 

f -i • u * 1 TELNET, WWW, or BBS. If the dial-up user requests a 

own lines for wide-area communication but can securely use , ' • ' t. a ^ . . ^^ - i 

the ublic Internet 15 non- VPN service, the Access Concentrator will simply 

^ forward the packets of the dial-up user to their destinations. 

The ISP 13 uses an Access Concentrator 17 and a database jf ^^^j.^p ^^^^ requests a VPN service, a second PPP 

18 for handling the communications of VPNs. The Access negotiation between the host machine of the dial-up user and 

Concentrator 17 provides two mterfaces: a VPN interface ^ ypj^ ^^^^ ^ estabhshed. If the second PPP nego- 

171 for providing point-to-point access using PSTN or ^^^^^^ ^ successful, the dial-up user wiU be assigned with 

ISDN lines, and an Internet interface 172 for providing ^ j^g^j ypN network address to access the VPN. 

TCP/IP protocol to pass trafiBc to the Internet 15 or non- Consequently, the dial-up user can access non- VPN service 

without having to directly connect to a VPN server. 

PPTP uses an enhanced GRE (Generic Routing 

Encapsulation) mechanism to provide a flow- and BRIEF DESCRIPTION OF THE DRAWINGS 

congestion-ojntrolled encapsulated da^gram service for y^^^ ^^^^ ^^^^^^ advantages of the present 

carrymg PPP packets. When a user 11 of a corporation uses ^^^^^^^^ ^^^^ ^^^^^ ^y reference to the follow- 

PPTP and dials up to the ISP 13, the packets will be ^ description and accompanying drawings wherein: 

encapsulated and then sent to the Access Concentrator 17. ^, „^ ^ . . . , 

The encapsulated PPP packets will be carried over IP. Thus, ^J^- ^ * schematic diagram showing the conventional 

the data format for the encapsulated packet is illustrated in system. 

FIG. 2. It includes a Media header 21, an IP header 22, a FIG. 2 is a schematic diagram showing the data format of 

GRE header 23, and then the PPP packet 24. an encapsulated PPP packet. 

A conventional Access Concentrator 17 will simply check 50 F^G. 3 illustrates the system of an Access Concentrator 

the authenticity of the dial-up user from the call ID of the which supports on-demand functions according to the pre- 

PPP packet and then assign a legal network address as a ^n-ed embodiment of the present invention, 

source address for the authenticated user to access the VPN FIG. 4 is a flow chart schematically showing the method 

without actually decrypting the PPP packets. In other words, of the present invention, 

the ISP 13 allows the dial-up user 11 to direcUy perform PPP 55 nPSPRIPTIOM OF THF 

negotiation with the server 14 in the user's company. ^^^^t^?Ji?r^wri;,S^^^ 

Consequently, if the dial-up user simply wants to browse the PREFERRED EMBODIMENTS 

World Wide Web, or using TELNET, FTP, he still has to FIG. 3 illustrates the system of an Access Concentrator 

connect -to the server 14 of the VPN 19. This is undesirable which supports on-demand functions according to the pre- 

because connecting to a remote server needs more time and ferred embodiment of the present invention. The Access 

traffic. Concentrator 31 operates on a dial access platform and can 

Besides, based on the current architecture of an Access control access for dial-in circuit switched calls originating 

Concentrator, if we want to add the on-demand function to from a PSTN or ISDN 32 or to initiate outbound circuit- 

a conventional Access Concentrator, the software must be switched connections. 

complied with the architecture of RADIOU Service (Remote 65 The Access Concentrator 31 also provides Physical native 

Authentication Dial-In User). In other words, the PPP itself interfacing device 33 to connect to public switch telephone 

has to be modified to support EAP standard (PPP extensible networks (PSTNs) 32. After the remote user dials in and 
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requests a Link layer negotiation with the ISP 30, the 409: perform a NCP negotiation with the VPN server; 

Link-layer Control Protocol (LCP) Controller 361 performs 410: assign a legal VPN network address to the dial-up 

a PPP Link Control Protocol for the remote user 34 to user,.such as an IP address or an IPX address; 

connect to the ISP 30. Then, an ID controller 362 performs .^^ . 

PPP authentication by looking up the VPN user database 35 5 41U: connect tne Vi-iN server -u ^ • ^ 1 

and confirms if the source address, rights, user ID, and ^ preferred embodunent has been described in detail 

password recorded on the packets are authenticate. If the hereinabove. It is to be understood that the scope of the 

user 34 is a legal VPN user, the PPP negotiation continues mvention also comprehends embodiments different from the 

to perform network layer negotiation using network layer described, yet within the scope of the claims. For 

control protocol. In contrast to simply forwarding the PPP example, the PPP negotiation protocol can be modified if 

packets, the Network Control Protocol (NCP) controller 363 ^ there is any similar protocol available in the future for VPN 

decrypts the packets to get the network address and service connections. Also, the on-demand menu is not limited to 

request information from the packets. After the PPP nego- FTP, FTP, BBS and WWW. Any new service may be added 

tiation is complete, the remote user 34 will be assigned with into the menu anytime when appropriate, 

a network address provided by the Access Concentrator 31, It should be understood that various alternatives to the 

such as an IP address. The designated IP address is different structures described herein may be employed in practicing 

from the registered IP address of the user's VPN server 35 the present invention. It is intended that the following claims 

so that the user does not have to connect to the VPN server define the invention and that the structure within the scope 

35 first before using other resources provided by the Access claims and their equivalents be covered thereby. 

Concentrator 31. The NCP controller 363 also determines What is claimed is* 

the routing protocol for the packets. 20 ^ ^ ^^^^^ \^ ^^^^^ Concentrator to provide 

Then, after the first PPP negotiation is complete, the on-demand services for Virtual Private Network (VPN) 

packets with a new network address will be transferred to the subscribers, comprising the steps of: 

service provider 37. The servke provider ^ Provides rf^^i^g , PPP negotiation with a host machine of 

on-demand services for the user 34 to choose. With the new j i u - 

J- 1 • f . t. • . c a dial-up user when receivmg a coimection request 

IP address, the dial-up user is free to choose various types of 25 f h h* 1 

non-VPN service, such as TELNET, FTP, BBS and WWW. ^^'"^ "^^^'""^ "^'^ 

If the user 34 chooses non-VPN services, the service pro- determining the authenticity of said dial-up user by look- 

vider 37 wiU directly forward those packets to their desti- up a VPN user database to check whether said 

nations without having to connect to the VPN server 35 in ^^I-up user withm said VPN user database; 

the user's company. On the other hand, if the user 34 30 assigning a network address to said dial-up user when said 

chooses VPN service, the second PPP negotiation with the dial-up user is determined to be authentic; 

company*s server will be established. In the second PPP performing a NCP negotiation to determine either said 

negotiation, the LCP controller 381 can adopt the user dial-up user demanding VPN services or non-VPN 

information from the first LCP negotiation, so the connec- services; 

tion can be established in a short time. Then, the packets will 35 jf ^^id dial-up user demanding a non-VPN service, pro- 
be transferred to the NCP controller 382 for establishing a viding the non-VPN service to said dial-up user by 
network layer communication with the VPN server 35. At reference to said network address; and 
this time, the user 11 gets a legal network address assigned jf ^^id dial-up user demanding a VPN-service, performing 
by the VPN server 35 of the user's company, such as an IP ^ second PPP negotiation with a VPN server and 
address or an IPX address, so that the user can access the 40 assigning a legal VPN network address for said dial-up 
resources m the VPN server 35. u^er to access said VPN server. 

Refer to FIG. 4 for showing the method of the invention 2. The method as claimed in claim 1, further comprising 

based on the system as illustrated in FIG. 3. The inventive gt^p of. 

method comprises the following steps: building a database for storing VPN user information. 

401: perform an LCP negotiation with the dial-up user 3. xhe method as claimed in claim 1, further comprising 

upon receiving a connection request; ({jg g^gp of: 

402: check the authenticity of the dial-up user by looking rejecting said first PPP negotiation when said dial-up user 

up a VPN user database. If the dial-up user is ^ determined to be authentic. 

authenticated, go to step 404. Otherwise, go to step 4 jhe method as claimed in claim 1, wherein said 

network address is an IP address. 

403: reject the connection request. 5. jhe method as claimed in claim 1, wherein said 

404: perform an NCP negotiation with the dial-up user, non-VPN service comprises: 

including decrypting the PPP packets to get the network TELNET FTP WWW and BBS. 

address and service request information from the PPP 5 xhe method' as claimed in claim 1, wherein said legal 

packets; VPN network address is an IP address. 

405: assign a new network address for the dial-up user; 7. The method as claimed in claim 1, wherein said legal 

406: provide an on-demand menu for the dial-up user to VPN network address is an IPX address. 

choose. If the user requests a non-VPN service, go to 8. The method as claimed in claim 1, further comprising 

step 407. If the user requests a VPN service, go to step 50 the step of: 

forwarding packets of said dial-up user to their destina- 

407: forward the packets to their destinations if the tions when said dial-up requests a non-VPN service. 

dial-up user chooses a non-VPN service, such as 9. The method as claimed in claim 1, wherein said second 

TELNET, FTP, BBS and WWW; PPP negotiation is based on user information obtained from 

408: perform an LCP negotiation with the VPN server 65 said first PPP negotiation, 

based on the information obtained from the first LCP 

negotiation; * « « 4< * 
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